简介
来源:漏洞战争
VMWare用得多,VMWare OVF Tools可能就很少用了,但是我们导入ovf文件时就要使用它
环境
Window7 虚拟机
od
windbg
注:VMware OVF Tool利用附件的安装包安装就好
基于输出消息的漏洞定位方法
先看poc了解一下
命令行打开poc
我们在最后留意到一个函数——capacityAllocationUnits,那个函数很有可能就是存在格式化字符串漏洞的函数了
这个直接用吾爱od带参数加载,会发现断不下来,那这个可以设置默认调试器,之后按上面图片的调试程序按纽即可
但用普通的可以,有可能只是调试选项设置的问题
下面是windbg
可以看到栈都是被00填充了,我们无法通过栈查找信息,或者说esp被修改了(当然只是猜测)
在当前exe的入口点搜索字符串——Invalid value,可以找到两处,但另外一处不符合,因为没有attribute(来到这我就跟着自己的思路调试了)
在上面的字符串双击跟过去发现,只是初始化字符串,那我就执行到返回,一步步f8,跟了挺久的,这个需要耐心
之后发现下面这个函数执行完就输出格式化串了
我们继续跟进,就是下面这个call edx
继续,最终在下面的basic_ostream调用输出了格式化字符串
我开始懵逼,没发现basic_ostream可以输出格式化字符串,以为这就只是一个cout,
以为我自己的调试方法不对,结果查看作者的,原来跟作者的惊人的一致
所以最终的结果是
还有一个小问题
还有一个问题就是问什么产生异常呢,
可以看到异常指令retn之前, esp和ebp的差值是很大的,而所以导致esp最后急剧地减小,指向一个没用过的栈,当然上面都是00,所以就出现了这个情况
那这个ebp被修改了吗?确实是被修改了
看下poc,最后有个%hn,就是至修改低两位
我们也可以计算一下最后写入的值是多少?为0x32a
所以这里跟上面的ebp的0x00120345的低4位0x345非常接近了,(由于函数调用ebp的值有些许改变)
不信的话可以看看格式化时候的栈
可以看到输出的最后一个数是00000004,那么后一个参数就是要写入的地址所以而这个地址正好的ebp,因为下面就是返回地址啊
漏洞利用
由于作者这个exp是适用于xp的,所以我的windows 7我看手动该改改能不能奏效
可以看到exp还是修改ebp
ebp修改为12fc3c
之后再出一层函数,esp就被修改为12fc3c了
ebp又变为12ff18
最后出来发现ebp指向我们的可控字符串
最后导致esp可控
所以我们只需修改下面这个的对应位置为jmp esp的地址,下面再填充字母版shellcode就行了
比如我修改如下:
最后即可跳到栈上执行shellcode了
在源码中就是修改这个位置为jmp esp地址就好了
后面修改为shellcode,注意长度不要变换,
我们将XP8A改为AAAA看看是不是去到0x41414141那里吧
确实可以,那我们生成一下字母shellcode
1 | ~# msfvenom -l encoders |
我们可以看到可以用大小写编码的,也可以用全大写的
但其实这个其实编码得不彻底
其实这个还是比较难搞的,直接修改返回地址为不可见字符
程序会抛出异常
我们来看看作者提供的shellcode,返回地址7852753d,都是可见字符,后面就是字母shellcode
所以这个对系统的版本还是比较苛刻的,就写到这吧